Storage Class Extensibility in the Brown Object Storage System

The Brown Object Storage System (BOSS) provides extensible support for persistence in a distributed multi-client, multi-server environment. BOSS is built on a loosely coupled, asynchronous computation model. One of the artifacts of asynchrony is increased extensiblity. This paper presents the storage class, the means by which the BOSS client interface is extended. The BOSS prototype is completed and operated in a network of Sparc10s running SunOS 4.1. Currently the untuned prototype operates at 6 short transactions (20 reads, 4 writes) per second. New applications such as CAD, hyper-media, and programming environments stress existing database technology to the limit 2]. Object Oriented Databases (OODBs) were developed to meet the demands of these new domains. OODBs support new application domains with extensible type systems that allow new abstractions to be added easily. All OODBs use some distinct service that provides stable storage for objects or pages, referred to as object servers and page servers respectively 11, 5, 19, 13, 1]. Whenever an OODB attempts to model a domain for which specialized secondary storage structures exist, the object store causes a problem. Concurrency control, recovery and other modules need to be changed in order to accommodate the new storage structure. An extensible object store would accommodate new interfaces without causing major disruptions to the existing system. The Brown Object Storage System (BOSS) achieves extensibility by providing well deened interfaces to the designers of specialized storage structures. Through these interfaces the designer augments the structure with correct concurrent operation, fault tolerance and client-server distribution. BOSS aims to minimally constrain storage structure designers. To this end, BOSS is constructed from loosely coupled entities that cooperate asynchronously through well deened interfaces that communicate by message passing.